SAA 模試3 カバー

数百万のリクエストは NLB を使え

数百万のインターネットトラフィックリクエストを処理するためには、Network Load Balancerを使用します。Application Load Balancerの性能では、数百万のインターネットトラフィックリクエストを処理するには不十分です。

EBSを定期バックアップしたいなら DLM

Amazon Data Lifecycle Manager (Amazon DLM)を活用することで、Amazon EBSのスナップショット取得に関するライフサイクルポリシーを設定することが可能

EBSのバックアップを有効にするだけでは、定期的なライフサイクルポリシーの設定は行えません。

DAXは高コストなので「一時的にパフォーマンスを向上したい」用途としては過剰

DynamoDB テーブルは、DynamoDB Accelerator (DAX) を有効にすることで、追加のキャッシュレイヤーを介してパフォーマンスを最大 10 倍向上させ、ミリ秒からマイクロ秒の範囲での応答を実現します。DAXはインメモリキャッシュを活用しており、特定のデータ処理を迅速化するための有効な手段です。しかし、インメモリキャッシュは高コストであるため、常時使用することは経済的ではありません。

DynamoDB ではリードレプリカの概念がない（DAXで内包）

DynamoDB にも AutoScaling は適用できる

API処理を必要としてないのにAPI Gateway使おうとするな

S3クロスリージョンレプリケーションは各バケットで設定必要、また設定すると変更イベントをトリガーにしてレプリケートされる

S3クロスリージョンレプリケーションを設定することで、S3バケット内のオブジェクトが作成、更新、または削除される際に発生するイベントをトリガーとして、別のS3バケットにオブジェクトデータのレプリケーションが行われます。

単一のクロスリージョンレプリケーション設定では、一方のバケットに対してのみレプリケーションが行われるため、バケット間の完全な同期は実現できません。双方向のクロスリージョンレプリケーションを行うには、両方のバケットで互いにクロスリージョンレプリケーションを設定する必要があります。

EKS では Secret Manager は不要、EKS 内部で完結できるらしい

Amazon EKSに保存されるすべてのシークレットは、Kubernetesシークレットと呼ばれるEKS独自のシークレットを利用して暗号化する

Amazon S3 Storage Lens

バージョニングが無効となっているS3バケットを特定することが可能です

Amazon S3 のストレージクラス分析

ストレージアクセスパターンを詳細に分析し、データを適切なストレージクラスに移行する最適なタイミングを見極めることが可能

IAM Access Analyzer for S3

パブリックバケットや AWS アカウント外で共有されているバケットなどのバケットアクセス許可の状況を解析

Glacier、ボールトロックポリシーを設定してから Vault Lock を設定すればポリシー変更をガードできる

👀問題文よく見ろ

1 DynamoDBストリームはイベント駆動なので、定期的な処理の実装には向いてない

2 ピーク時間帯にSQSキューが満杯になっていることが原因とされているため、DynamoDB DAXクラスターを用いてキャッシュを保持することは無意味です。

3 Auto Scalingグループを構成するAmazon EC2インスタンス上にコンテナアプリケーションを実装するために、ユーザー側でソフトウェアを用いて環境を整備する必要があります。したがって、最小限の運用上のオーバーヘッドという要件には合致しません。

IAMデータベース認証

EC2インスタンスに適用することで、EC2インスタンスからIAMデータベース認証を利用してRDSのDBインスタンスにアクセスできるようになります

NLB の HTTP ヘルスチェックからは Auto Scaling のアクションにはつなげられない

アクションに繋がる部分まで意識しなければいけない🐰

UnhealthyHostCountのメトリクスをモニタリングするAmazon CloudWatchアラームを作成する。アラームがALARM状態になると異常状態のインスタンスを置換するように、Auto Scalingアクションを構成する。

たとえば cloudwatch アラームならアクションも叩ける

オンプレのIP範囲をAWSに移行したいときは Route Origin Authorization (ROA)

Route Origin Authorization (ROA) を利用して、AWSアカウントに対して特定のIPアドレスを移行する

この仕組みを活用することで、パブリックにルーティング可能なIPv4またはIPv6アドレス範囲の一部または全体を、オンプレミスのネットワークからAWSアカウントに移行することができます。アドレス範囲をAWSに設定すると、その範囲はAWSアカウント内のアドレスプールとして表示されます。

RAID覚えてないのでおさらい

RAID 0: データを複数ディスクに分散して高速化するが、冗長性はない。

RAID 1: データを複数ディスクに同時保存して冗長性を高める（ミラーリング）。

RAID 5: 複数ディスクに分散書き込みしつつ、パリティで1台障害に耐えられる。

RAID 6: 複数ディスクに分散・2つのパリティで2台の障害に耐えられる。

VPCフローログ + Redshiftクラスターに対して拡張VPCルーティング有効化

拡張VPCルーティングを利用することで、Redshiftはクラスターとデータリポジトリ間の全てのCOPYおよびUNLOADトラフィックがVPCを経由するように設定されます。

なるほど、redshift側からvpcに流す設定をするわけか🐰

Lambdaは自動でスケーリングする、ユーザーが手動で有効にするといった概念はない

APIリクエストにおける一時的な高負荷に対応するためには、Amazon API Gatewayの処理能力を向上させることが重要

そのためには、APIゲートウェイのスロットリング制限を設定し、キャッシュ機能を有効にする必要があります。

ALBはEC2インスタンスのトラフィックを複数のAWSリージョンに分散させることはできません

ALBは、単一のリージョン内で複数のアベイラビリティゾーンに対してトラフィックを分散させます。

可用性だからリージョンへの分散だろと思ったら違った、知らねえよそんなの🐰

Approximate Number Of Messages属性

Amazon SQSキューのメッセージ数に基づいてスケーリングを実施できる

リクエスタ支払い

S3バケットのクロスアカウントアクセスを有効化し、リクエスタ支払い機能を導入することで、ヨーロッパの企業が所有するAWSアカウントからS3バケットへのアクセスを許可しつつも、データ取得にかかる費用をヨーロッパ企業に負担させることが可能となります

CloudFrontにキャッシュ範囲を変更する的な概念はない

キャッシュ対象のオブジェクトの範囲によって配信効率を変更する設定は存在しません。キャッシュの保持期間を適切に設定することが重要です。

Amazon CloudFrontのディストリビューション設定において、Cache-Controlのmax-ageディレクティブやTTLが低い値に設定されていることが原因です。このため、キャッシュの保持期間が極めて短くなり、キャッシュの期限切れが頻発し、結果としてリクエストがオリジンサーバーに頻繁に送信されることになります。

地理的近接はパフォ目的、近接の名前のとおりパフォ目的って感じ ← これで覚えよう

24/7稼働ならリザーブドインスタンス使っていい

API Gateway は REST API の方が高機能

CloudFrontディストリビューションを通じて音声ファイルを配信することで、高速な音声配信を行う際にはREST APIを利用する方が最適です。HTTP APIはREST APIに比べて機能が制限されていますが、コア機能の提供に絞ることで低レイテンシかつ低コスト（コスト最適化）を実現します。